In recent years object oriented programming has become increasingly popular. Object oriented programming systems provide capabilities for defining object oriented data and program code (known as object methods or functions) to manipulate that data. In this way object oriented programming systems emphasize abstract data types and the intrinsic operations that can be performed on those data types. Such systems effectively hide the complexity of a program itself, as well as hiding the data. Object oriented programming is described generally in many texts. Two examples of such texts are "The C++ Programming Language", Second Edition, by Bjarne Stroustrup, published by Addison-Wesley Publishing Company, Reading Mass., copyright AT&T Bell Laboratories, Inc. 1991 and "Using C++", by Bruce Eckel, published by Osborne McGraw-Hill, Berkeley Calif., Copyright 1989.
As object oriented programming has increased in popularity, software developers have used object oriented techniques to provide services from the software systems they develop. An example of a software system based on object oriented principles is Microsoft.RTM. OLE. Microsoft.RTM. OLE is an object oriented software system consisting of a unified environment of object-based services having the capability of both customizing those services and extending the environment through custom services.
As discussed herein, the user of an object service is referred to as the "client", while the provider of the service is the "server". For example where a user has embedded a spreadsheet into a word processing document, the spreadsheet is being served by a server process to the client process which is the word processor. Object oriented programming systems are desirable in that they provide transparent inter-operation among servers and clients for sharing information.
Computer programs (software) are often developed for a particular processor architecture (or "computer architecture"), that is they are compiled into a specific processor instruction set. Exemplary processor architectures include the Alpha.RTM. architecture by Digital Equipment Corporation, assignee of the present invention, the so-called X86 architecture on which is based a family of microprocessors designed and built by manufacturers including the Intel.RTM. Corporation, as well as others such as the PowerPC.RTM. designed and built by Motorola, IBM and Apple, the VAX.RTM. architecture by Digital Equipment Corporation and the PARISC.RTM. architecture by Hewlett-Packard. Descriptions of processor architectures are sometimes publicly available. For example the Alpha.RTM. architecture is described in "Alpha AXP Architecture Reference Manual", Second Edition, by Richard L. Sites and Richard T. Witek, Copyright 1995, published by Digital Press, Boston Mass. An example of the X86 architecture standard is described in "Pentium Processor Family Developer's Manual", Volumes 1 through 3, Copyright 1995, published by Intel Corporation, Mt. Prospect Ill. A description of the VAX.RTM. architecture is found in "VAX Architecture Reference Manual", edited by Timothy E. Leonard, Copyright 1987, published by Digital Press, Boston Mass.
New processor architectures often provide significant performance improvements. However computer program users may not easily be able to recompile or modify computer programs developed for older processor architectures on new processor architectures.
Accordingly, in many situations it is desirable or necessary to operate a multicode execution environment. A multicode execution environment supports execution of programs developed for dissimilar processor architectures. In an example multicode execution environment, a program (or "code") developed for execution on a processor architecture of an underlying hardware system is referred to as "native code", and a program developed for execution on a different processor architecture is referred to as "non-native code". For purposes of example, the processor architecture of the underlying hardware system is referred to herein as "Architecture A", and an example different processor architecture is referred to as "Architecture B".
A problem arises in using object oriented programming systems in a multicode execution environment. The problem is that object methods or functions defined to be applied to the object oriented data may be developed for execution by a server executing on a first architecture (i.e. native code), but accessed from a client executing in an execution engine of a second (different) architecture (i.e. non-native code). In a multi-code execution environment where the object server process is executing on an execution engine for a first architecture, and where the client process is executing on an execution engine for a second architecture, there is needed a system for executing the object methods or functions from the client process. Further, the object methods themselves must be able to access system services by executing other object methods that may be produced for dissimilar processor architectures than the method is executing in.
In addition, objects in the Microsoft.RTM. OLE service architecture present a particular difficulty in that the objects themselves can be shared between the client and the server at run time, and the mechanism which holds the address of each object method function is shared between the client and the server. This situation may lead to the server or client processes attempting to execute a method function designed for the other process's execution engine. In existing systems the result of this would be errors or program failure.
Thus there is needed a system which allows use of object oriented services in a multicode execution environment where the service objects may be accessed from either an execution engine for the architecture for which their functions were written, or from an execution engine for a dissimilar architecture. The system should maintain transparency to a user such that object methods are executed without user intervention regardless of the code in which they were developed or the process from which they are accessed.
The new system should allow a user to use objects including object methods developed for a second architecture while the user has invoked and is executing a process or application for a first architecture. Such transparency is advantageous in a desk-top environment where user intervention is highly undesirable. The new system should also provide inter-operability between programs developed for a first architecture and those developed for a second architecture substantially free from any end user involvement. The system should further allow use of object methods developed for a first architecture where such use provides optimal performance because the first architecture is the native code architecture of the system on which the code is being run.